Aurora2(MySQL5.7互換)のDB環境をAurora3(MySQL8.0互換)へアップグレードしてみた

最新の Aurora3 (MySQL8.0 互換) のDBエンジンでサポートされる、Aurora　Serveless v2 などの新機能を利用するため、Aurora2　(MySQL5.7互換)のDBエンジンバージョンのアップグレードを行ってみました。

#Amazon Aurora

#AWS

suzuki.ryo

2022.04.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWSチームのすずきりょうです。

MySQL5.7互換のDBエンジン Aurora 2 を利用している環境で、 Aurora3 (MySQL8.0 互換) のDBエンジンで提供される機能を利用するため、 DBエンジンバージョンの更新を実施する機会がありましたので、紹介させていただきます。

Database engine updates for Amazon Aurora MySQL version 3

方針

最新のAurora3のDBエンジンに更新し、MySQL8の新機能、Aurora Serveless v2 を利用可能にする
DBのメンテナンス時間は1時間以内とする
メンテナンス中、一般公開中のページ閲覧への影響は回避する。

アップデート対象

EngineVersion

アップデート前: 5.7.mysql_aurora.2.10.2 (Aurora2: MySQL5.7互換)
アップデート後: 8.0.mysql_aurora.3.02.0 (Aurora3: MySQL8.0.23互換)

スペック

リージョン: 東京
インスタンスクラス: db.r6g.large
ストレージ容量(Volume Bytes Used) : 約14GB

事前検証

アップデートを実現する方法と、その所要時間を確認しました。

インプレースアップグレード

2022年4月時点、Aurora 2から、Aurora3へのインプレースアップグレードは未サポート。今回のアップグレード手段として利用できませんでした。

スナップショットからのリストア

手動スナップショットの作成、Aurora3エンジンでのリストアによる移行を試みました。

スナップショット作成: 2分
リストア: 約20分
アプリケーション設定変更: 約3分

mysqldump

MySQL標準のCLIツール「mysqldump」コマンドを利用した、エクスポート、インポートを試みました。

新規DBクラスタ作成: 20分
ダンプ(エクスポート): 1分30秒
ダンプ(インポート): 5分20秒
アプリケーション設定変更: 約3分

DBのメンテナンス時間は10分弱で済む事が確認できたため、「mysqldump」によるエクスポート、インポートでDB移行を行う事としました。

未評価

リストアや「mysqldump」の所要時間が1時間以上となる場合、以下を評価予定でした。

Percona XtraBackup

レプリケーション

手順

Aurora3 DBクラスタ作成

Aurora3用パラメータグループ作成

CloudFormationを利用して、Aurora3 用のパラメータグループを作成
設定値は Aurora2 で利用していた、文字コード設定などを踏襲
aurora_lab_mode など、Aurora2 の評価に利用していた項目は除外

Resources:
  RdsdbClusterParameterGroup:
    Type: AWS::RDS::DBClusterParameterGroup
    Properties:
      Description: CloudFormation Aurora3 Cluster Parameter Group
      Family: aurora-mysql8.0
      Parameters:
        character_set_server: utf8
        character_set_client: utf8
        character_set_connection: utf8
        character_set_results: utf8
        character_set_database: utf8
  RdsdbParameterGroup:
    Type: AWS::RDS::DBParameterGroup
    Properties:
      Description: CloudFormation Aurora3 Parameter Group
      Family: aurora-mysql8.0
      Parameters:
        slow_query_log: 1
        long_query_time: 1000
        log_output: FILE

Aurora3 DBクラスタ作成

移行元の Aurora2 のDBクラスタを踏襲したVPC設定
パラメータグループは、Aurora3用に作成したものを利用

ダンプ処理

mysqldump実行環境

Amazon Linux 2のAMIを利用してEC2を起動
Amazon Linuxのエクストラリポジトリの mariadb パッケージを利用しました。

sudo amazon-linux-extras install -y mariadb10.5 -y
mysqldump --version
mysqldump  Ver 10.19 Distrib 10.5.10-MariaDB, for Linux (aarch64)

予めSSMパラメータストアに保存したDB接続情報を mysqldump、msql で利用しました

export AWS_DEFAULT_REGION="ap-northeast-1"
ParameterName='xxxx-aurora2'
TMP=`aws ssm get-parameter \
    --name "${ParameterName}" \
    | jq -r .Parameter.Value`

ADMIN_USER=`echo ${TMP} | jq -r .admin_user`
ADMIN_PASS=`echo ${TMP} | jq -r .admin_pass`
DB_ENDPOINT_RW=`echo ${TMP} | jq -r .db_endpoint_rw`
DB_NAME=`echo ${TMP} | jq -r .db_name`
DB_USER=`echo ${TMP} | jq -r .db_user`
DB_PASS=`echo ${TMP} | jq -r .db_pass`
echo -e "ADMIN_USER: ${ADMIN_USER} \nDB_NAME: ${DB_NAME} \nDB_USER: ${DB_USER} \nDB_ENDPOINT_RW: ${DB_ENDPOINT_RW} \nDB_ENDPOINT_RO: ${DB_ENDPOINT_RO}"

if [ -f ~/.my.cnf ]; then   chmod 600 ~/.my.cnf; fi
echo -e "[client] \npassword=\"${ADMIN_PASS}\"" > ~/.my.cnf
chmod 400 ~/.my.cnf

ダンプ(エクスポート)

GZ圧縮状態で500MB程度のDBダンプファイル、EC2上のローカルに出力
整合性を確保するため「--single-transaction」指定

time mysqldump  -h ${DB_ENDPOINT_RW} -P 3306 -u ${ADMIN_USER} ${DB_NAME} --single-transaction
 | gzip > dmp.gz

ダンプ(インポート)

Aurora3 に新規データベース、アプリケーション用のDBユーザを作成、インポートを実施

ParameterName='xxxx-aurora3'
TMP=`aws ssm get-parameter \
    --name "${ParameterName}" \
    | jq -r .Parameter.Value`

ADMIN_USER=`echo ${TMP} | jq -r .admin_user`
ADMIN_PASS=`echo ${TMP} | jq -r .admin_pass`
DB_ENDPOINT_RW=`echo ${TMP} | jq -r .db_endpoint_rw`
DB_NAME=`echo ${TMP} | jq -r .db_name`
DB_USER=`echo ${TMP} | jq -r .db_user`
DB_PASS=`echo ${TMP} | jq -r .db_pass`
echo -e "ADMIN_USER: ${ADMIN_USER} \nDB_NAME: ${DB_NAME} \nDB_USER: ${DB_USER} \nDB_ENDPOINT_RW: ${DB_ENDPOINT_RW} \nDB_ENDPOINT_RO: ${DB_ENDPOINT_RO}"

if [ -f ~/.my.cnf ]; then   chmod 600 ~/.my.cnf; fi
echo -e "[client] \npassword=\"${ADMIN_PASS}\"" > ~/.my.cnf
chmod 400 ~/.my.cnf

echo "CREATE DATABASE ${DB_NAME} " | mysql -h ${DB_ENDPOINT_RW} -P 3306 -u ${ADMIN_USER}
echo "CREATE USER ${DB_USER} IDENTIFIED BY '${DB_PASS}';" |  mysql -h ${DB_ENDPOINT_RW} -P 3306 -u ${ADMIN_USER}
echo "GRANT ALL PRIVILEGES ON ${DB_NAME}.* TO ${DB_USER};FLUSH PRIVILEGES;" | mysql -h ${DB_ENDPOINT_RW} -P 3306 -u ${ADMIN_USER}

time zcat dmp.gz | mysql -h ${DB_ENDPOINT_RW} -P 3306 -u ${ADMIN_USER} ${DB_NAME}

ログ(エクスポート、インポート)

$ time mysqldump -h ${DB_HOST} -P 3306 -u ${ADMIN_USER} ${DB_NAME} --single-transaction | gzip > dmp.gz

real    1m22.803s
user    1m43.180s
sys     0m3.251s

$ ls -lah *.gz
-rw-rw-r-- 1 ec2-user ec2-user 513881441 Apr 25 09:04  dmp.gz

$ time zcat dmp.gz | mysql -h ${DB_HOST} -P 3306 -u ${ADMIN_USER} ${DB_NAME}

real    5m18.453s
user    0m35.593s
sys     0m2.980s

環境変数

DBを利用するアプリケーションの環境変数を更新しました。

今回のアプリケーションは Elastic Beanstalk で動作する環境であるため、EBの環境変数設定を更新、DB接続先のエンドポイントをAurora3クラスタのものとしました。

動作、性能確認

アプリケーションへのログイン操作が可能な事を確認しました。

パフォーマンスインサイト

Aurora2、Aurora3 変更前後の DBクラスタの負荷状況を確認しました。

Aurora2

DBLoad値(0.5前後)で遷移

Aurora3

DBLoad値(1前後)で遷移

アプリ遅延

Aurora3を参照する Lambda (SSR処理用) のAPI Gatewayのメトリックの遅延発生状況を確認しました。

Aurora3に DBエンジン更新した後、DB負荷が上昇する副作用が確認されましたが、 DB性能限界に十分な余裕がある事、アプリの遅延影響が軽微である事から切り戻しは行わず、後日、実行計画やインデックスの再調整などを試みる事としました。

後日作業

Aurora3へのアップグレード後、処理効率が悪化したSQLをパフォーマンスインサイトで特定。実行計画の確認や、インデックス追加などによる改善を試みました。

パフォーマンスインサイト

Aurora2

Aurora3

Aurora3に変更後、DBの専有時間が10倍近く増えた処理(SELECT)が数件存在しました。

実行計画確認

遅くなったSQLのサンプルをパフォーマンスインサイトで取得、実行計画を確認しました。

> EXPLAIN SELECT post_date_gmt FROM wp_posts WHERE post_status = 'publish' AND post_type IN ('post', 'page', 'attachment') ORDER BY post_date_gmt DESC LIMIT 1;
+----+-------------+----------------+------------+-------+------------------+------------------+---------+------+-------+----------+---------------------------------------+
| id | select_type | table          | partitions | type  | possible_keys    | key              | key_len | ref  | rows  | filtered | Extra                                 |
+----+-------------+----------------+------------+-------+------------------+------------------+---------+------+-------+----------+---------------------------------------+
|  1 | SIMPLE      | wp_posts | NULL       | range | type_status_date | type_status_date | 164     | NULL | 62062 |   100.00 | Using index condition; Using filesort |
+----+-------------+----------------+------------+-------+------------------+------------------+---------+------+-------+----------+---------------------------------------+
1 row in set, 1 warning (0.01 sec)

日付カラムを対象としたソート処理に、インデックスが活用できていない状況でした。

インデックス調整

検証環境(クローン)を増設し、インデックスの追加と効果測定を試みました。

> create index idx_post_date_gmt on wp_posts(post_date_gmt);
Query OK, 0 rows affected (0.81 sec)
Records: 0  Duplicates: 0  Warnings: 0

ソート処理にインデックスが利用されている事が実行計画確認できました。

> EXPLAIN SELECT post_date_gmt FROM techblog_posts WHERE post_status = 'publish' AND post_type IN  ('post', 'page', 'attachment') ORDER BY post_date_gmt DESC LIMIT 1;
+----+-------------+----------------+------------+-------+------------------+-------------------+---------+------+------+----------+----------------------------------+
| id | select_type | table          | partitions | type  | possible_keys    | key               | key_len | ref  | rows | filtered | Extra                            |
+----+-------------+----------------+------------+-------+------------------+-------------------+---------+------+------+----------+----------------------------------+
|  1 | SIMPLE      | wp_posts | NULL       | index | type_status_date | idx_post_date_gmt | 5       | NULL |    5 |    19.35 | Using where; Backward index scan |
+----+-------------+----------------+------------+-------+------------------+-------------------+---------+------+------+----------+----------------------------------+
1 row in set, 1 warning (0.00 sec)